2025-08-31 객체지향 정글 스터디 ch07, appendix-a
SCRAPS
[225] 설계를 간단히 끝내고 최대한 빨리 구현에 돌입하라. 머릿속의 객체 협력구조가 번뜩인다면 그대로 코드를 구현하기 시작하라.
∵ 설계물은 인터페이스를 식별하고 구현하는 과정에서 필연적으로 변동된다. [222] 설계작업은 구현을 위한 스케치를 작성하는 단계이지, 구현 그 자체일 수 없다. 설계에 이상이 없는지, 구현가능한지 판단할 수 없다, 언제? 설계과정에서는.
[227] 어떤 메시지가 있을 때 그 메시지를 수신할 객체를 어떻게 선택하는가?
저자가 얘기를 하다가 만 것 같은데, 저서 "오브젝트"에는 좀 더 자세하게 나온다. 오브젝트 - 코드로 이해하는 객체지향 설계 - 조영호#^grasp
- 정보전문가(Information Expert): 책임을 완수할 가능성이 높기 때문에 정보전문가에게 책임을 할당하는 것이 유리. 여기에서 말하는 정보란, 책임에 필요한 값, 정보를 알고 있는 다른 객체와의 관계, 계산식 보유 등을 의미한다. 따라서 이런 정보전문가 객체에게 책임을 할당하면 추가적인 맥락을 전달할 필요가 줄어들어 결합도가 줄어들게 된다.
- 창조자(Creator): 책임의 종류가 "생성"일 경우 창조자에게 해당 책임을 할당하라. 어떤 객체가 다른 객체를 사용, 초기화, 포함해야 할 일이 있을때 고려할 수 있다.
- 낮은 결합도(Low Coupling): 객체 후보군들에 책임을 하나씩 할당해보았을 때 결합도를 계산해보라. 결합도의 총합이 가장 작은 객체에게 책임을 할당하라.
- 결합도 계산법:
결합도 ≈ Fan-in + Fan-out
- Fan-in: 특정 객체를 호출하는 외부 객체의 개수
- Fan-out: 특정 객체가 호출하는 외부 객체의 개수
- 결합도 계산법:
- 높은 응집도(High Cohesion): 객체가 너무 많은 책임을 지지 않도록 조절하라. 신 객체가 탄생하게 되면 모든 관심사와 인지부하가 그 객체에게 쏠리게 된다.
- 응집도 계산법: 2025-08-31 객체지향 정글 스터디 ch07, appendix-a#^lcom 참조
[232] 분류란, 객체들을 동일한 타입 또는 범주로 묶는 과정을 의미한다. 따라서 동일한 범주에 속한 객체들을 타입의 인스턴스라고 부른다. 분류의 역은 타입에 해당하는 객체를 생성하는 과정으로 인스턴스화라고 한다.
객체는 컴퓨터의 은유로, 메모리 공간과 몇가지 오퍼레이션 집합을 포함할 뿐, 범주를 알거나 구별하지 않는다. 인스턴스화는 컴파일러, 인간이 처음 객체를 생성할 때부터 범주 안에 객체를 넣어버리는 걸 의미한다. 그렇게 어떤 객체를 인스턴스로 부르다가 보면 어느순간 런타임에 인스턴스의 맥락을 잃거나 변화하는 순간이 올 지도 모른다는 생각이 들었다. 하지만 잇츠오케. 새 객체를 다시 만들지 않더라도 재-인스턴스화가 가능할지도 모른다. 대표적인 예시로 다운캐스팅, 대리자 패턴, 합성 패턴 등이 있을 것 같다.
[235] + 그림.A.5. 다중분류와 동적분류 관점에서 도메인 모델의 초안을 만든 후 실제 구현에 적합하도록 단일분류와 정적분류 방식으로 객체들의 범주를 재조정하는 편이 분석과 구현간의 차이를 메울 수 있는 가장 현실적인 방법이다.
[244] 클래스 간 위임(delegation) 사슬을 계층 내에서 어떤 클래스가 메시지를 처리하거나 최상위 부모 클래스에 위임될 때까지 계속된다.
클래스가 없는 프로토타입 기반 언어에서 상속은 객체와 객체 간의 관계로 이루어진다.